Codeless provisioning sync rules

ABSTRACT

Managing resources. A computing environment may include a resource manager. The resource manager includes programmatic code for managing resources. Expected rule entries are added to an expected rules list. Each of the expected rule entries includes: an indicator used to identify a synchronization rule, a definition of flow type, a specification of an object type in the resource manager to which the synchronization rule applies, a specification of a downstream resource system, a specification of an object type in the downstream resource system to which the synchronization rule applies, a specification of relationship criteria including one or more conditions for linking objects in the resource manager and the downstream resource system, and a specification of attribute flow information. Objects in downstream resource systems can be synchronized with objects in the resource manager based on the expected rule entries in the expected rules list.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.61/032,389, filed Feb. 28, 2008 titled “Codeless Provisioning”, which isincorporated herein by reference in its entirety.

BACKGROUND Background and Relevant Art

Computers and computing systems have affected nearly every aspect ofmodern living. Computers are generally involved in work, recreation,healthcare, transportation, entertainment, household management, etc.

In many computing enterprises it is often desirable to grant permissionsto entities working within the enterprise to allow entities to accesscertain resources within the enterprise. For example, when an individualis hired at a company it may be appropriate to assign the individualaccess to e-mail by creation of an e-mail account, access to certaindatabases by creation of database access accounts, or access to otherresources.

Various resource manager systems have been created to manage entitypermissions within an enterprise. The resource manager systemscommunicate with other resource systems in the enterprise to provide theother resource systems with instructions to add or remove permissionsfor entities. For example, Identity Lifecycle Manager® (ILM) provided byMicrosoft® Corporation of Redmond Wash. provides the ability to manageentity permissions within an enterprise. However, many such systemsrequire that a programmer create imperative programming code that allowsthe resource manager system to communicate with the other resourcesystems to cause the systems to add the appropriate permissions forentities. This of course may add additional complexity and difficulty toresource management functionality. The subject matter claimed herein isnot limited to embodiments that solve any disadvantages or that operateonly in environments such as those described above. Rather, thisbackground is only provided to illustrate one exemplary technology areawhere some embodiments described herein may be practiced.

BRIEF SUMMARY

Embodiments may be directed to managing resources in an enterprise. Acomputing environment may include a resource manager. The resourcemanager includes programmatic code for managing resources in theenterprise. Expected rule entries are added to an expected rules list.Each of the expected rule entries includes: an indicator used toidentify a synchronization rule, a definition of flow type specifyingthat the synchronization rule can be used for at least one of importingdata into the resource manager from a downstream resource system orexporting data from the resources manager to a downstream resourcesystem, a specification of an object type in the resource manager towhich the synchronization rule applies, a specification of a downstreamresource system, a specification of an object type in the downstreamresource system to which the synchronization rule applies, aspecification of relationship criteria including one or more conditionsfor linking objects in the resource manager and the downstream resourcesystem, and a specification of attribute flow information. Objects indownstream resource systems can be synchronized with objects in theresource manager based on the expected rule entries in the expectedrules list.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Additional features and advantages will be set forth in the descriptionwhich follows, and in part will be obvious from the description, or maybe learned by the practice of the teachings herein. Features andadvantages of the invention may be realized and obtained by means of theinstruments and combinations particularly pointed out in the appendedclaims. Features of the present invention will become more fullyapparent from the following description and appended claims, or may belearned by the practice of the invention as set forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features can be obtained, a more particular descriptionof the subject matter briefly described above will be rendered byreference to specific embodiments which are illustrated in the appendeddrawings. Understanding that these drawings depict only typicalembodiments and are not therefore to be considered to be limiting inscope, embodiments will be described and explained with additionalspecificity and detail through the use of the accompanying drawings inwhich:

FIG. 1 illustrates a topology including a resource manager anddownstream connected resource systems;

FIG. 2 illustrates a method of creating objects in downstream resourcesystems;

FIG. 3 illustrates a method of removing permissions from objects indownstream resource systems;

FIG. 4 illustrates a method of adding permissions to objects indownstream resource systems; and

FIG. 5 illustrates a method of coordinating detected permissions withexpected or desired permissions.

DETAILED DESCRIPTION

Embodiments described in herein allow for the implementation of aresource manager system that synchronizes objects in a resource managerwith objects in other downstream resource systems by executing declaredworkflows as appropriate. In particular, using resource manager objectscorrelated to downstream resource system objects, appropriatepermissions can be granted in the downstream resource system objects soas to grant appropriate permissions to entities corresponding to theresource manger objects and downstream resource system objects. Thisallows the entities to access resources in the downstream resourcesystems. The following discussion illustrates a number of examples ofhow this functionality is implemented. In particular, a resource managercan be used to control what objects exist in downstream resourcesystems. The existence of objects in downstream resource systems allowsfor the functionality of those systems to be used and appropriatecontrols over resources implemented. For example, if a user objectexists in a downstream resource system, the user object may providefunctionality for allowing a computer user to access resources on theresource system. For example, if a user is to be granted access to anemail system, a user object will typically need to be created in theemail system. Similarly, if a user is to be granted access to data in adata storage system, a user object for the user will need to be createdin the data storage system. A resource manager can facilitate creationof these user objects in the downstream systems including the emailsystem, the data storage system, or other resource systems.

Previously there has been no mechanism to control how data flows betweentwo systems in a purely declarative manner. Some embodiments describedherein include a unified model, based around the concept of a“synchronization rule” along with policy rules and process to replaceprevious models with one that provides a single set of concepts thatallows, through for example, the use of visually created processes andsynchronization rules, the definition of how data is to flow both intoand out of a resource manager to downstream resource systems. Inparticular, embodiments described herein may include functionality forexporting objects at a resource manager to downstream resource systems,importing objects at downstream resource systems into a resource manger,and functionality for updating or deleting existing objects in aresource manager and corresponding objects in downstream resourcesystems.

A customer can use a resource manager portal, including a graphical userinterface, to define synchronization rules, which encapsulate thedetails of how data is to flow in and out of a resource manager. Theresource manager portal may include a graphical user interface includinguser interactive elements for receiving user input defining one or moreobjects, including object name and object type, managed by a resourcemanager, flow type for synchronizing objects managed by a resourcemanager with objects in one or more downstream resource systems,identification of one or more downstream resource systems,identification of object types in downstream resource systemscorresponding to the one or more object types in the resource manager,and definition of relationship criteria for correlating objects indownstream resource systems with objects in the resource manager. Inparticular, a synchronization rule may define the relationship andtransformation between a resource manager object and objects indownstream resource systems. For example, a relationship may be based ona username, email address, or other identifier. The synchronization rulemay define: how the resource manager creates objects in a downstreamresource system, how the resource manager creates objects in its ownstore, and how data flows from a downstream resource system and aresource manager object. The customer can then use policy rules andprocess designer wizards to control the application of those particularsynchronization rules to modifications of data within the resourcemanager application store.

For example, embodiments may implement graphical user interface elementsfor a synchronization rule designer application that allow an ITprofession to design synchronization rules. In one embodiment, thegraphical user interface of the synchronization rule designer may be ina wizard format with “General Information,” “Scope,” “Relationship,”“Outbound Attribute Flow,” and “Inbound Attribute Flow” screens.

The “General Information” screen allows a designer to define a name fora rule, a description for a rule, dependencies for a rule, and flow typefor a rule. The name is a name that can be used to identify asynchronization rule. The description is an optional description of therule that can include any description deemed applicable by the designer.A dependency on the existence of another synchronization rule can alsobe set. In one embodiment, the “General Information” screen provides apull-down menu for selecting already defined synchronization rules. Aswith other graphical user interface elements described herein, otherinterfaces may alternatively be used. The “General Information” screenmay also include an interface for selection of flow type. For example, auser can define the rule as an inbound rule allowing for importing ofdata into the resource manager and/or an outbound rule allowing forexporting of data to a downstream system.

The synchronization rule designer application may further include a“Scope” screen. The “Scope” screen, in the example embodiment may allowfor selecting a resource manager object type, selecting a downstreamresource system, selecting a downstream system object type, and/ordefining connected object scope. Defining connected object scope may beperformed by defining one or more filters that identifies to whichobjects in a downstream resource system a synchronization rule will beapplied. In one embodiment, the synchronization rule applies to objectsin the downstream resource system which match all conditions defined inthe connected object scope.

The synchronization rule designer application may further include a“Relationship” screen. The “Relationship” screen includes user interfaceelements for defining how a relationship between a resource manager anda downstream resource system are identified and created. In particular,the “Relationship” screen allows for defining relationship criteria andrelationship creation. User interface elements allowing for thespecification of relationship criteria allow for specifying conditionsthat link together objects in the resource manager and in the downstreamresource system. Various attributes may be selected, such as emailaddresses, usernames, etc. Additionally, various conditions may bespecified. The “Relationship” screen may also allow for specifying thatan object can be created if relationship criteria specified in thedefined relationship criteria are not satisfied. A user can specify thatan object is created in the resource manager if absent from the resourcemanager, an object is created in a downstream resource system if absentfrom a downstream resource system, that an object hierarchy is createdin a downstream resource system and/or that an object is are deletedfrom a downstream resource system when an object is removed from theresource manager.

The synchronization rule designer application may further include an“Outbound Attribute Flow” screen. The “Outbound Attribute Flow” screenincludes user interface elements for defining attributes and values toflow from the resource manager to the downstream resource system. The“Outbound Attribute Flow” user interface elements allow for thedefinition of a source field, to identify the data to flow from theresource manager to an attribute in the downstream resource system; thedestination, to identify the attribute in the downstream resource systemto receive data identified in the source field; and options. Forexample, a user may specify an option whereby an attribute only flowswhen the destination object is created. Further, a user may select anoption to specify that the attribute is used to flow to test thepresence of a synchronization rule on a destination object. Thesynchronization rule designer application may further include an“Inbound Attribute Flow” screen. The “Inbound Attribute Flow” screenincludes similar user interface elements to the “Outbound AttributeFlow” screen except that flow is defined from downstream resourcesystems to the resource manager.

A business manager designer application provides a graphical userinterface that allows a business manger to add or remove synchronizationrules to or from resource manager objects. Adding or removing may beperformed by manual selection or be selected to be performedautomatically based on attribute values.

A canonical scenario includes the provisioning of new users through aresource manager into downstream systems such as various email systems,database systems, or other systems. Provisioning may include, forexample, adding permissions for a new employee to appropriate systemresources to allow the employee to perform necessary work functions.FIG. 1 will now be used to illustrate an example. Note that in FIG. 1,various components may be described generically or specifically. Forexample, a generic reference to a resource manager object 106 refers toany and all resource manager objects generically while specificreferences to resource manager object instances may be made by referenceto an additional parenthetical designator such as resource manager 106a. Similar references and designations are illustrated in FIG. 1 forsynchronization rules 102, expected rules lists 104, downstream resourcesystem objects 108, and detected rules lists (DRLs) 112. Also note thatalthough not discussed specifically, some specific representations, suchas 102 b, 104 b 106 b, 112 b, 108 b-108 f, 114 b and 114 c are includedto illustrates that multiple specific instances of an item may beincluded in a computing environment. However, the remaining principlescan be understood by reference to the single instances referred tobelow.

Illustrating now an example, in the case of provisioning, and referringonce again to FIG. 1, synchronization rules 102 can be defined andincluded in expected rules lists (ERLs) 104 at the resource manager 110that encapsulate how to transform what is created as resource managerobject type into downstream resource system objects. The synchronizationrules can be defined in some embodiments by using the graphical userinterface as described above. Notably, synchronization rules 102 may beincluded explicitly in the expected rules list 104 or may be definedseparate from the expected rules lists 104 and included by reference inthe expected rules lists 104 as appropriate. Illustrating now anexample, the synchronization rule 102 a may indicate how to transformresource manager object 106 a, when created or modified, to acorresponding downstream resource object 108 a at the downstreamresource system 114 a. A synchronization rule 102 may define both howdata is to flow from the resource manager 110 to the downstream resourcesystem object 108, as well as specific instructions on how to find analready existing downstream resource system object 108 to flow data toas well as further instructions on how, if desired, to create a newdownstream resource system user object 108 if a suitable one is notfound.

Once a synchronization rule 102 is defined, a customer can then define apolicy rule around the creation of new resource manager objects 106 inthe resource manager 110 as they arrive through its resource managementservice. From here, the customer can construct a resource managerprocess, associated to the action phase of an event that will add thenewly created resource manager object 106 to the synchronization rule102 defined previously. The ultimate result being that when a newresource manager object 106 is created in the resource manager 110, anevent will be generated that causes this action process to run andsignal that this newly created resource manager object 106 is to havethe synchronization rule 102 applied to it.

Using these constructs, a user can create arbitrarily complex processes,such as in the form or declarative workflows, which add and removeobjects in the resource manager 110 to synchronization rules 102 asneeded and dictated by their own business process.

The termination or de-provisioning scenario in which a user is leavingthe company can be handled in a similar manner as the creation scenario,just that a process will be defined to run on the event of a resourcemanager object 106 being deleted from the resource manager system andthat process will remove that deleted resource manager object 106 fromthe synchronization rule 102. Note that declarative workflows differfrom imperative programming in the declarative objects in declarativeworkflows define an end goal without defining specific acts toaccomplish the goal. In contrast, imperative programming requires aprogrammer to define explicitly each step without necessarily definingthe end goal.

Embodiments described herein may include definitions of bidirectionaldata flow logic within the concept of a synchronization rule 102.Further embodiments may include the application of synchronization rules102 by virtue of matching of a policy rule and execution of a subsequentresource manager process.

Embodiments may be directed to both processing of synchronization rulesby a synchronization engine, as well as the rules application torelevant resource manager objects 106 done through the resource managerrequest processing cycle (which, in one embodiment, processes end userweb service requests through three distinct phases: authentication,authorization and action).

Within the single structure of synchronization rules, a customer definesboth the relationship between an object in a downstream resource systemand one in a resource manager metaverse as well as the flow of databetween the two. In previous versions of resource managers, this singlestructure did not exist, but rather a user would have to define theinbound flow of data through a single set of concepts(Join/Projection/Inbound Flow) that were independent from those whichgoverned the flow of data outbound from the resource manager (Programmedlogic+Outbound flow). In some embodiments, the synchronization ruledefines a new set of concepts which is meant to treat both directions offlow the same, while at the same time eliminating the need for anyprogramming as part of this structure.

Synchronization rules are run both when importing changes from adownstream resource system into the resource manager (‘inbound’), aswell as when exporting changes from the resource manager to a downstreamresource system (‘outbound’).

In any direction, a synchronization rule may operate by scoping theappropriate set of objects, then looking for or establishing arelationship with an object in the other system, and then applying thetransformation specified as part of the rule between the source objectand the target object found as part of the relationship.

When looking at the direction of flow being from a downstream resourcesystem to the resource manager, scoping may be achieved through astraight attribute-value filter which is used to collect the necessaryset of objects in the downstream resource system upon which asynchronization rule should be applied to on import.

However, when looking at synchronization from the resource managerperspective, set memberships, policy rules and process may be thedictators of which objects are brought in and out of scope of asynchronization rule rather than a straight filter as is used on theinbound case. Specifically, when looking at the resource manager, theremay be no automatic filter which collects users within the scope of arule, instead each resource manager object has associated a list ofsynchronization rules to which the resource manager object should beapplied. This list is referred to herein as the expected rules list 104.When a synchronization rule appears on a resource manager object'sexpected rules list 104, that resource manager object is then manuallyadded to the scope of the associated synchronization rule upon the nextrun of the synchronization engine. It is expected that synchronizationrules are added and removed from a resource manager object's expectedrules 104 list through action processes in a declarative workflow whichuse the synchronization rule activity to manipulate the expected ruleslist. These action workflows may be expected to launch as a result ofnormal resource manager operations on its objects.

Additionally, each resource manager object 106 also has an associatedlist which visualizes what synchronization rules are confirmed to existon that resource manager object in the real world, this list is calledthe detected rules list 112. The detected rules list 112 and expectedrules list 104 may be completely independent of each other and are onlyapplicable from a resource manager centric view. That is, the expectedrules list 104 is used for outbound synchronization and the detectedrules list 112 is used for looking at a resource manager object'srepresentation in downstream systems. In FIG. 1, 108 a is a downstreamrepresentation of 106 a.

A detected rules list 112 may be created by identifying objects inconnected downstream systems 114 and correlating the objects withobjects in the resource manager 110. Resource manager objects 106 can becreated in the resource manager 110 as necessary to account for objects108 discovered in downstream resource systems. Often downstream resourcesystems 114 may include objects 108 granting permissions to entities ofwhich the resource manager 110 is not aware. Creation of a detectedrules list 112 provides functionality for identifying these objects 108in downstream systems 114. The expected rules list 104 can then beupdated to either note the objects 108 in the downstream systems 114 orto remove permissions, by removing downstream resource system objects108 from the downstream systems 114 or to remove permission from thedownstream system objects 108.

The expected rules list 104 and detected rules list 112 constructs allowfor a user to both look at what a representation of resource managerobject 106 is supposed to look like in downstream systems 114 as adownstream resource system object 108, as well as confirm what thatrepresentation actually is. The detected rules list 112 provesespecially useful for compliance reporting, in that a single attributewill display the known representation of that particular resourcemanager object 106 as it is known to correspond to downstream resourcesystem objects 108 in other systems.

As mentioned above, if the synchronization rule is being evaluated inthe inbound direction, the scoping of an object may be done via thefilter. If it is being evaluated in the outbound leg, each object'sexpected rules list 104 may used to determine which objects fall intothe scope of the synchronization rule 102.

The following discussion now refers to a number of methods and methodacts that may be performed. It should be noted, that although the methodacts may be discussed in a certain order, no particular ordering isnecessarily required unless specifically stated, or required because anact is dependent on another act being completed prior to the act beingperformed.

Referring now to FIG. 2, a method 200 is illustrated. The method 200 maybe practiced for example in a computing environment including a resourcemanager. The resource manager includes programmatic code for managingresources. The method 200 includes an act of receiving user inputindicating that a new entity should be added to the resource manager(act 202). For example, in the example illustrated in FIG. 1, a user maydesire to add a new object such as resource manager object 106 a to theresource manager 110. A user may indicate, using a user interfacecoupled to the resource manager 110, the desire to add the resourcemanager object 106 a.

In response to receiving user input indicating that a new entity shouldbe added to the resource manager, the method 200 further includescreating a new entity object corresponding to the new entity (act 204)and generating an event (act 206). For example, a resource managerobject 106 a may be added to the resource manager repository and anevent may be generated. The event may specify a workflow that should beexecuted. The workflow is configured to add synchronization rules 102 toan expected rules list 104 a particular to the new entity object. Forexample, a workflow may be configured to add the synchronization rule102 a to the expected rules list 104 a. Synchronization rules 102 on theexpected rules list define how to transform objects 106 at the resourcemanager 110 into objects 108 at downstream resource systems 114. Inparticular, synchronization rules 102 may define how one or more entityobjects 108 are created in a downstream resource system 114, how one ormore entity objects 106 are created at the resource manager 110 and howdata flows from a downstream resource system 114 to a resource managerobject 106. Additionally, synchronization 102 rules may define within asingle synchronization rule 102, one or more of an inbound, outbound, orbi-directional relationship between a downstream resource system 114 andthe resource manager 110.

The method 200 further illustrates that in response to the event, theworkflow specified in the event is executed causing synchronizationrules to be added to the expected rules list (act 208). As illustratedin FIG. 1, the synchronization rule 102 a is added to the expected ruleslist 104 a. Notably, adding synchronization rules to an expected ruleslist may be performed in a number of different fashions. For example, asynchronization rule 102 a may be stored in a rule repository at theresource manager 110. The synchronization rule 102 a may be added to theexpected rules list 104 a by reference to a synchronization rule in therule repository. Alternatively, a rule may be added to the expectedrules list explicitly by direct definition in the expected rules list104 a. In other words, an expected rules list 104 may serve as therepository for synchronization rules 102 in the expected rules list 104.

The method 200 may further be practiced such that at a synchronizationengine of the resource manager, a workflow is executed to synchronizethe new entity object with corresponding objects in downstream resourcesystems managed by the resource manager so as to cause the creation ofpermissions for the new entity in the downstream resource systems byexecuting the synchronization rules in the expected rules list. Forexample, the synchronization engine may reference the synchronizationrule 102 a in the expected rules list 104 a. The synchronization enginemay determine that the resource manager object 106 a should besynchronized with the downstream resource system object 108 a at thedownstream resource system 114 a. As will be described in more detailbelow, this may be accomplished by correlation of an existing downstreamresource system object 108 with a resource manager object 106 or bycreation of a new downstream resource system object 108 to correspondwith the resource manager object 106.

For example, the method 200 may be performed where causing the creationof permissions for the new entity in the downstream resource systemsincludes determining that an object corresponding to the new entityobject does not exist in the downstream resource system; and creating anobject in the downstream resource system corresponding to the new entityobject at the resource manager. In the example illustrated in FIG. 1,the downstream resource system object 108 a may not exist in thedownstream resource system 114 a when the synchronization engineexecutes a workflow to synchronize the synchronization rule 102 a tosynchronize the resource manager object 106 a with the downstreamresource system object 108 a. Thus, embodiments may include creating thedownstream resource system object 108 a in the downstream resourcesystem 114 a. This allows for further synchronization in granting ofappropriate rights and permissions.

In one embodiment the method 200 may be practiced where executing aworkflow to synchronize the new entity object with corresponding objectsin downstream resource systems managed by the resource manager includesexecuting synchronization rules according to precedence specified forthe synchronization rules. The precedence specifies synchronizationrules that should be executed before other synchronization rules. Forexample, the expected rules list 104 a may include a number ofsynchronization rules including rules 102 a through 102 n. However, itmay be desirable to perform the synchronization specified in somesynchronization rules 102 before the synchronization specified in otherrules. This may be done for example to ensure that permissions orrestrictions specified in one rule are not overwritten by the laterapplication of a different synchronization rule.

Referring now to FIG. 3, a method 300 is illustrated. The method 300illustrates the number of acts that may be performed in a computingenvironment including a resource manager. The resource manager includesprogrammatic code for managing resources in the computing environment.The method 300 includes acts for managing resources including managingpermissions for entities to access the resources. The method includesreceiving user input indicating that an entity represented by an entityobject of the resource manager should have permissions removed at theresource manager (act 302). For example, a user interacting with a userinterface connected to the resource manager 110 may indicate that anentity corresponding to a resource manager object 106 a should havepermissions removed from downstream resource systems 114. For example,if the entity is an employee at an organization and the role of theentity is changed, it may be necessary to remove certain permissionsfrom a certain downstream resource systems 114 such that the entity canno longer access, or perform certain access actions at resources at thedownstream resource systems 114. Such may be indicated by anadministrator interacting with the resource manager 110.

In response to receiving user input that an entity should havepermissions removed at the resource manager, an event is generated (act304). The event specifies a workflow that should be executed. Theworkflow is configured to cause synchronization rules in an expectedrules list particular to the entity object to indicate that permissionsshould be removed for the entity in one or more downstream resourcesystems. For example, a synchronization rule 102 a may be modified toindicate that permissions should be removed from a downstream resourcesystem object 108 a.

The method 300 may further include in response to the event, executingthe workflow specified in the event (act 306) causing synchronizationrules to indicate that permissions should be removed for the entity inone or more downstream resource systems.

The method 300 may further include, at a synchronization engine of theresource manager, executing a workflow to synchronize the entity objectwith corresponding objects in downstream resource systems managed by theresource manager so as to cause the removal of permissions for theentity in the downstream resource systems. For example a workflow may beconfigured to reference the synchronization rule 102 a and tosynchronize a resource manager object 106 a with a downstream resourcesystem object 108 a where such synchronization results in the removal ofpermissions for the downstream resource system object 108 a.

In one embodiment, the method 300 may be practiced where causingsynchronization rules in an expected rules list particular to the entityobject to indicate that permissions should be removed for the entity indownstream resource systems includes adding new synchronization rules tothe expected rules list. For example, a new synchronization rule 102 maybe added to an expected rules list 104 indicating that permissionsshould be removed.

In one embodiment, the method 300 may further include generating adetected rules list, where the detected rules list specifies existingpermissions for the entity object for resources in an the computingenvironment. Generating a detected rules list includes examining objectsin downstream resource systems and correlating the examined objects indownstream resource systems with resource manager objects managed by theresource manager. Executing the workflow specified in the event causingsynchronization rules to be removed from the expected rules list (act306) includes causing a workflow to be executed that causes existingpermission from the detected rules list to be removed from the expectedrules list.

For example, as has been discussed above and as will be discussed inmore detail below the detected rules list 112 a may determine that adownstream resource system object 108 a includes certain permissionsthat are undesirable to be granted to an entity corresponding to thedownstream resource system object 108 a. To remove these permissions,the synchronization rule 102 may be added to the expected rules list 104a which specifically removes the permissions from the downstreamresource system object 108 a.

In an alternative embodiment, causing synchronization rules in anexpected rules list particular to the entity object to indicate thatpermissions should be removed for the entity in downstream resourcesystems may include modifying existing synchronization rules in theexpected rules list. For example, if the synchronization rule 102 a isincluded on the expected rules list 104 a and grants certain permissionsto the downstream resource system object 108 a, removal of thepermissions may be accomplished by modifying the synchronization rule102 a.

FIG. 4 illustrates yet another embodiment that may be practiced in acomputing environment including a resource manager. The resource managerincludes programmatic code for managing resources in the computingenvironment. The method of managing resources includes managingpermissions for entities to access the resources. The method 400includes receiving user input indicating that an entity represented byan entity object of the resource manager should have permissions addedat the resource manager (act 402). For example, a resource managerobject 106 a corresponding to an entity may exist in the resourcemanager 110. An administrator interacting with the resource manager 110may provide user input indicating that additional permissions should beadded in downstream resource systems 114 for the resource manager object106 a.

The method 400 further illustrates that in response to receiving userinput that an entity should have permissions added at the resourcemanager, an event is generated (act 404). The event specifies a workflowthat should be executed. The workflow is configured to causesynchronization rules in an expected rules list particular to the entityobject to indicate that permissions should be added for the entity inone or more downstream resource systems. As illustrated in previousexamples, a synchronization rule 102 a may be added to an expected ruleslist 104 a, or modified if the appropriate synchronization rule 102 aalready exists in the expected rules list 104 a, to allow for an eventto indicate that permissions should be added to a downstream resourcesystem object 108 a.

The method 400 further includes in response to the event, executing theworkflow specified in the event causing synchronization rules toindicate that permissions should be added for the entity in one or moredownstream resource systems (act 406).

The method 400 may further include at a synchronization engine of theresource manager, executing a workflow to synchronize the entity objectwith corresponding objects in downstream resource systems managed by theresource manager so as to cause the creation of permissions for the newentity in the downstream resource systems by executing thesynchronization rules in the expected rules list. For example, aworkflow may be configured to reference the synchronization rule 102 ain the expected rules list 104 a so as to synchronize and/or otherwisecreate permissions in the downstream resource system object 108 a.

As noted previously, several embodiments make use of a detected ruleslist where the detected rules list defines an actual state ofpermissions in downstream resource systems for an entity. Thus, someembodiments may be directed to generating the detected rules list andmaking appropriate use of the detected rules list. For example, themethod 500 may be practiced In a computing environment including aresource manager, the resource manager comprising programmatic code formanaging resources in the computing environment, the method 500 includesgenerating a detected rules list (act 502). The detected rules listspecifies existing permissions for an entity for resources in acomputing system. Generating a detected rules list includes examiningobjects in downstream resource systems and correlating the examinedobjects in downstream resource systems with resource manager objectsmanaged by the resource manager.

The method 500 further includes accessing an expected rules list (act504). The expected rules list defines permissions that should exist forthe entity for resources in the computing system. For example, anexpected rules list may define how synchronization should be performedbetween a resource manager object 102 and a corresponding downstreamresource system object 108. Permissions can be inferred or determinedfrom the rules in the expected rules list 104.

The method 500 further includes comparing the detected rules list to theexpected rules list and determining that the detected rules listincludes permissions not included in the expected rules list (act 506).For example, the detected rules list 104 a may be compared to thedetected rules list 112 a. Based on the comparison, a determination maybe made that the detected rules list 112 a includes permissions for anentity that are not included in the expected rules list 104 a.

An indication can be provided that the detected rules list includespermissions not included in the expected rules list (act 508).

The method 500 may further include receiving user input indicating thepermissions included in the detected rules list and not included in theexpected rules list should be removed. This embodiment further includesin response to the user input, removing the permissions included in thedetected rules list and not included in the expected rules list bymodifying the expected rules list and executing a workflow. The workflowis configured to cause the removal of permissions in downstream resourcesystems. In one embodiment, modifying the expected rules list includesincluding an entry in the expected rules list indicating removal of oneor more permissions.

In one embodiment of the method 500, correlating the examined objects indownstream resource systems with objects managed by the resource managerincludes determining that an object does not exist in the resourcemanager that can be correlated with an object in the downstream resourcesystem. An object is created in the resource manager to correlate withthe object in the downstream resource system.

The method 500 may be practiced where the expected rules list includesone or more synchronization rules. Each of the one or moresynchronization rules may include a number of parameters. For example,each of the one or more synchronization rules may include an indicatorused to identify the synchronization rule. Each of the one or moresynchronization rules may include, a definition of flow type specifyingthat the synchronization rule can be used for at least one of importingdata into a the resource manager from a downstream resource system orexporting data from the resources manager to a downstream resourcesystem. Each of the one or more synchronization rules may includespecification of an object type in the resource manager that thesynchronization rule applies to. Each of the one or more synchronizationrules may include specification of a downstream resource system. Each ofthe one or more synchronization rules may include specification of anobject type in the downstream resource system to which thesynchronization rule applies. Each of the one or more synchronizationrules may include specification of relationship criteria including oneor more conditions for linking objects in the resource manager and thedownstream resource system.

Embodiments may be implemented where each of the one or moresynchronization rules may optionally include specification of attributeflow information. Each of the one or more synchronization rules mayoptionally include a description of the synchronization rule. Each ofthe one or more synchronization rules may optionally include informationdefining a dependency on the existence of another synchronization rule.Each of the one or more synchronization rules may optionally include afilter used for identifying objects in the downstream resource system towhich the synchronization rule will be applied. The filter may includeconditions that must be satisfied to apply the synchronization rule.

Each of the one or more synchronization rules may optionally includespecification of relationship creation acts that can be used when therelationship criteria specified in the relationship criteria is notsatisfied. For example, the relationship creation acts may includecreation of an object in the resource manager if absent from theresource manager. Alternatively or additionally, relationship creationacts may include creation of an object in a downstream resource systemif absent from the downstream resource system. Alternatively oradditionally, relationship creation acts may include creation of anobject hierarchy in a downstream resource system. Alternatively oradditionally, relationship creation acts may include deletion of anobject from a downstream resource system when a corresponding object isremoved from the resource manager.

Embodiments herein may comprise a special purpose or general-purposecomputer including various computer hardware, as discussed in greaterdetail below.

Embodiments may also include computer-readable media for carrying orhaving computer-executable instructions or data structures storedthereon. Such computer-readable media can be any available media thatcan be accessed by a general purpose or special purpose computer. By wayof example, and not limitation, such computer-readable media cancomprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to carry or store desired program code means inthe form of computer-executable instructions or data structures andwhich can be accessed by a general purpose or special purpose computer.When information is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired or wireless) to a computer, the computer properly views theconnection as a computer-readable medium. Thus, any such connection isproperly termed a computer-readable medium. Combinations of the aboveshould also be included within the scope of computer-readable media.

Computer-executable instructions comprise, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions. Although the subject matter has been described inlanguage specific to structural features and/or methodological acts, itis to be understood that the subject matter defined in the appendedclaims is not necessarily limited to the specific features or actsdescribed above. Rather, the specific features and acts described aboveare disclosed as example forms of implementing the claims.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

1. In a computing environment including a resource manager, the resourcemanager comprising programmatic code for managing resources in anenterprise, a method of managing resources including managingpermissions for entities to access the resources, the method comprisinggenerating a detected rules list, the detected rules list specifyingexisting permissions for an entity for resources in an enterprise,wherein generating a detected rules list comprises examining objects indownstream resource systems and correlating the examined objects indownstream resource systems with resource manager objects managed by theresource manager; accessing an expected rules list, the expected ruleslist defining permissions that should exist for the entity for resourcesin the enterprise; comparing the detected rule list to the expected rulelist and determining that the detected rule list includes permissionsnot included in the expected rule list; providing an indication that thedetected rules list includes permissions not included in the expectedrules list.
 2. The method of claim 1, further comprising: receiving userinput indicating the permissions included in the detected rules list andnot included in the expected rules list should be removed; in responseto the user input, removing the permissions included in the detectedrules list and not included in the expected rules list by modifying theexpected rules list and executing a workflow, wherein the workflow isconfigured to cause the removal of permissions in downstream resourcesystems.
 3. The method of claim 2, wherein modifying the expected ruleslist comprises including an entry in the expected rules list indicatingremoval of one or more permissions.
 4. The method of claim 1, whereincorrelating the examined objects in downstream resource systems withresource manager objects managed by the resource manager comprises:determining that an object does not exist in the resource manager thatcan be correlated with an object in the downstream resource manager; andcreating an object in the resource manager to correlate with the objectin the downstream resource manager.
 5. The method of claim 1, whereinthe expected rules list comprises one or more synchronization rules,wherein each of the one or more synchronization rules comprises: anindicator used to identify the synchronization rule; a definition offlow type specifying that the synchronization rule can be used for atleast one of importing data into the resource manager from a downstreamresource system or exporting data from the resources manager to adownstream resource system; specification of an object type in theresource manager that the synchronization rule applies to; specificationof a downstream resource system; specification of an object type in thedownstream resource system to which the synchronization rule applies;specification of relationship criteria including one or more conditionsfor linking objects in the resource manager and the downstream resourcesystem; and specification of attribute flow information.
 6. The methodof claim 5, wherein at least one of the one or more synchronizationrules further comprises a description of the synchronization rule. 7.The method of claim 5, wherein at least one of the one or moresynchronization rules comprises information defining a dependency on theexistence of another synchronization rule.
 8. The method of claim 5,wherein at least one of the one or more synchronization rules furthercomprises a filter used for identifying objects in the downstreamresource system to which the synchronization rule will be applied. 9.The method of claim 8, wherein the filter comprises conditions that mustbe satisfied to apply the synchronization rule.
 10. The method of claim5, wherein at least one of the one or more synchronization rules furthercomprises specification of relationship creation acts that can be usedwhen the relationship criteria specified in the relationship criteria isnot satisfied, wherein the relationship creation acts comprise one ormore of: creation of an object in the resource manager if absent fromthe resource manager; creation of an object in a downstream resourcesystem if absent from the downstream resource system; creation of anobject hierarchy in a downstream resource system; or deletion of anobject from a downstream resource system when a corresponding object isremoved from the resource manager.
 11. A method of creating rules foruse in an expected rule list, the rules configured to be used insynchronizing objects at a resource manager with objects at one or moredownstream resource systems for granting and removing permissions toaccess resources at the downstream resource systems, the methodcomprising: displaying a user interface, the user interface comprisinguser selectable components for receiving user input; at the userinterface, receiving user input specifying an indicator used to identifya synchronization rule; at the user interface, receiving user inputspecifying a definition of flow type specifying that the synchronizationrule can be used for at least one of importing data into the resourcemanager from a downstream resource system or exporting data from theresources manager to a downstream resource system; at the userinterface, receiving user input specifying a specification of an objecttype in the resource manager that the synchronization rule applies to;at the user interface, receiving user input specifying a specificationof a downstream resource system; at the user interface, receiving userinput specifying a specification of an object type in the downstreamresource system to which the synchronization rule applies; at the userinterface, receiving user input specifying a specification ofrelationship criteria including one or more conditions for linkingobjects in the resource manager and the downstream resource system; atthe user interface, receiving user input specifying a specification ofattribute flow information; and forming a synchronization rule definedby the user input.
 12. The method of claim 11, further comprisingstoring the synchronization rule in an expected rules list.
 13. Themethod of claim 11, further comprising at the user interface, receivinguser input specifying a description of the synchronization rule.
 14. Themethod of claim 11, further comprising at the user interface, receivinguser input specifying information defining a dependency on the existenceof another synchronization rule.
 15. The method of claim 11, furthercomprising at the user interface, receiving user input specifying afilter used for identifying objects in the downstream resource system towhich the synchronization rule will be applied.
 16. The method of claim11, further comprising at the user interface, receiving user inputspecifying conditions that must be satisfied to apply thesynchronization rule.
 17. The method of claim 11, further comprising atthe user interface, receiving user input specifying relationshipcreation acts that can be used when the relationship criteria specifiedin the relationship criteria is not satisfied, wherein the relationshipcreation acts comprise one or more of: creation of an object in theresource manager if absent from the resource manager; creation of anobject in a downstream resource system if absent from the downstreamresource system; creation of an object hierarchy in a downstreamresource system; or deletion of an object from a downstream resourcesystem when a corresponding object is removed from the resource manager.18. In a computing environment including a resource manager, theresource manager comprising programmatic code for managing resources inan enterprise, a method of managing resources including managingpermissions for entities to access the resources, the method comprisingadding expected rule entries to an expected rules list, wherein each ofthe expected rule entries comprises: an indicator used to identify asynchronization rule; a definition of flow type specifying that thesynchronization rule can be used for at least one of importing data intothe resource manager from a downstream resource system or exporting datafrom the resources manager to a downstream resource system; aspecification of an object type in the resource manager that thesynchronization rule applies to; a specification of a downstreamresource system; a specification of an object type in the downstreamresource system to which the synchronization rule applies; aspecification of relationship criteria including one or more conditionsfor linking objects in the resource manager and the downstream resourcesystem; and a specification of attribute flow information; andsynchronizing objects in downstream resource systems with objects at theresource manager based on the expected rule entries in the expectedrules list.
 19. The method of claim 18, wherein at least one of theexpected rule entries comprises a specification of relationship creationacts that can be used when the relationship criteria specified in therelationship criteria is not satisfied, wherein the relationshipcreation acts comprise one or more of: creation of an object in theresource manager if absent from the resource manager; creation of anobject in a downstream resource system if absent from the downstreamresource system; creation of an object hierarchy in a downstreamresource system; or deletion of an object from a downstream resourcesystem when a corresponding object is removed from the resource manager;and wherein synchronizing objects in downstream resource systems basedon the expected rule entries in the expected rules list comprises atleast one of: creating an object in the resource manager; creating anobject in a downstream resource system; creating an object hierarchy ina downstream resource system; or deleting an object from a downstreamresource system.
 20. The method of claim 18, wherein at least one of theexpected rule entries comprises a specification of a filter used foridentifying objects in the downstream resource system to which thesynchronization rule will be applied and wherein synchronizing objectsin downstream resource systems based on the expected rule entries in theexpected rules list comprises using the filter to identify which objectsin a downstream resource system a synchronization rule will be applied.